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Abstract 

We present techniques for reasoning about constructor classes that 
(like the monad class) fix polymorphic operations and assert poly- 
morphic axioms. We do not require a logic with first-class type 
constructors, first-class polymorphism, or type quantification; in- 
stead, we rely on a domain-theoretic model of the type system in a 
universal domain to provide these features. 

These ideas are implemented in the Tycon library for the Is- 
abelle theorem prover, which builds on the HOLCF library of do- 
main theory. The Tycon library provides various axiomatic type 
constructor classes, including functors and monads. It also provides 
automation for instantiating those classes, and for defining further 
subclasses. 

We use the Tycon library to formalize three Haskell monad 
transformers: the error transformer, the writer transformer, and 
the resumption transformer. The error and writer transformers do 
not universally preserve the monad laws; however, we establish 
datatype invariants for each, showing that they are valid monads 
when viewed as abstract datatypes. 

Categories and Subject Descriptors F.3.1 [Logics and Meanings 
of Programs]: Specifying and Verifying and Reasoning about Pro- 
grams - mechanical verification. 

Keywords denotational semantics, monads, polymorphism, theo- 
rem proving, type classes 

1. Introduction 

As a pure functional language, Haskell promises to work well for 
equational reasoning and proofs. Having programs and libraries 
that satisfy equational laws is important, because it lets program- 
mers think about the correctness of their code in a modular and 
composable way. 

Type classes are a valuable abstraction mechanism for writing 
reusable code in Haskell. Many Haskell type classes also have laws 
associated with them. Haskell programs that use these type classes 
often rely on the assumption that the laws hold. For example, a li- 
brary might implement a datatype of balanced search trees, with 
elements of type a. To permit comparisons between elements, the 
search tree operations use the class constraint Ord a, which pro- 
vides the comparison operator (<) :: a — > a — > Bool. But just hav- 
ing an operation of the right type is not enough: For the operations 



/^vTHIIF!^^ ^° tne extent possible under law, Brian Huffman has waived all 
\v copyright and related or neighboring rights to "Formal Verification 

1 of Monad Transformers". This work is published from: Germany. 

ICFP'12, September 9-15, 2012, Copenhagen, Denmark. 



to work correctly, the library requires (<) to satisfy some additional 
properties, e.g. that (<) is a total order. 

Much Haskell code is written with equational properties in 
mind: Programs, libraries, and class instances may be expected to 
satisfy some laws, but unfortunately, there is no formal connection 
between programs and properties in Haskell. Haskell compilers are 
not able to check that properties hold. One way to get around this 
limitation is to verify our Haskell programs in an interactive proof 
assistant, or theorem prover. 

Isabelle/HOL. Isabelle/HOL (or simply "Isabelle") is a generic 
interactive theorem prover, with tools and automation for reasoning 
about inductive datatypes and terminating functions in higher-order 
logic 1131 . Isabelle has an ML-like type system extended with 
axiomatic type classes 1171 . In Isabelle, a type class fixes one or 
more overloaded constants, just like in Haskell. But Isabelle also 
allows us to specify additional class axioms about those constants. 

As an example, here we have an axiomatic class Ord that fixes 
an order relation (<) and asserts that it is a total order: 

class Ord a where 

(<) :: a — > a — > Bool 

x < x 

x < y A y < z => x < z 
x < y A y < x ==> x = y 
x < y V y < x 

(Note that free variables appearing in class axioms are treated 
as universally quantified.) To establish an instance of class Ord 
in Isabelle, a user must not only provide definitions of the class 
operations, but also proofs that the operations satisfy the class 
axioms. 

Isabelle/HOLCF. Isabelle/HOLCF is a library of domain theory, 
formalized within the logic of Isabelle/HOL l5ll!2l . It is designed 
to support denotational reasoning about programs written in pure 
functional languages like Haskell. HOLCF can deal with programs 
that are beyond the scope of Isabelle/HOL's automation: HOLCF 
provides tools for defining and working with (possibly lazy) recur- 
sive datatypes, general recursive functions, partial and infinite val- 
ues, and least fixed-points. These features make Isabelle/HOLCF 
a useful system for reasoning about a significant subset of Haskell 
programs. With the combination of HOLCF and axiomatic classes, 
users can directly formalize many Haskell programs that use ad hoc 
overloading, and verify generic programs that may rely on laws for 
class instances. 

Type constructor classes. In addition to ordinary type classes, 
Haskell also supports type constructor classes. An ordinary type 
constraint like Ord a involves a type variable a :: *. The opera- 
tions in such a type class have relatively simple types like (<) :: 
(Ord a) => a — > a — > Bool, where no other type variables besides 
the one in the class constraint are mentioned. That is, for a specific 
class instance, the operations are monomorphic: e.g. to define an in- 



stance Ord Int, we have an operation (< Int ) ::Int—¥ Int — > Bool. (In 
other words, a dictionary for class Ord contains only monomorphic 
functions.) On the other hand, a constructor class like Functor r 
fixes a type variable of a higher kind, in this case r :: * —¥ *. Fur- 
thermore, the operations in a constructor class are usually polymor- 
phic. For example, fmap :: (Functorr) => (a — > B) — > ra — > tB also 
is polymorphic over the type variables a and B. The laws for the 
functor class are likewise polymorphic: For functors we usually as- 
sume that fmap id = id and fmap (fog) = fmap f o fmap g. For 
a specific functor class instance, these laws can be instantiated at 
various types. For a proper, law-abiding functor, we expect these 
laws to hold at all possible type instantiations. 

These additional requirements pose some real challenges for 
formal verification. While Isabelle has built-in support for ordinary 
axiomatic type classes, its type system does not natively support 
axiomatic constructor classes or type quantification — in fact, it 
does not even support higher-kinded type variables at all. Other 
interactive theorem provers exist with stronger type systems (e.g. 
Coq), but switching would mean giving up all the special support 
for reasoning about strictness, partial values, and general recursion 
in HOLCF. Coq and similar provers use a logic of total, terminating 
functions; thus proofs conducted in them are only applicable to the 
total, terminating fragment of the Haskell language. 

Contributions. Using a universal domain and a domain-theoretic 
model of types, we construct a library for Isabelle/HOLCF that 
gives users first-class type constructors and axiomatic constructor 
classes. Users can instantiate constructor classes by defining the 
constants and proving the class axioms at a single type. Using a 
combination of type coercions and naturality laws, theorems can 
then be transferred automatically to other type instances. 

This work builds upon and improves an earlier formalization 
of constructor classes in Isabelle, which was joint work with 
Matthews and White |7|. While some concepts (e.g. representable 
types, the type application operator, and coercions) remain un- 
changed, this paper also introduces several new contributions: 

• New simplified definition of class Functor 

• Fully automatic tools for constructing Functor class instances 

• A general, practical method for defining subclasses of Functor 

• Automation for transferring theorems between types, using co- 
ercions and naturality laws 

• Verification of error and writer monad transformers as abstract 
datatypes 

Outline. The remainder of the paper is organized as follows. 
We begin by reviewing relevant information about HOLCF: After 
a summary of basic domain-theoretic concepts (i|2j, we discuss 
the deflation model used to represent types in HOLCF (ij3). The 
next sections cover the implementation of the Tycon library: We 
show how to define the various constructor classes (Q, and then 
how to instantiate them (Sj5|. Next we discuss the verification of 
monad transformers with Tycon (ij6|. Finally, we conclude with a 
discussion of related and future work ((jT). 

2. Domain theory in HOLCF 

We now review the basic domain theory definitions used in HOLCF. 
A partial order is a set or type with a binary relation (C) that is 
reflexive, transitive, and antisymmetric. A chain is a countable in- 
creasing sequence: io C ij C x% C . . . A complete partial order 
(cpo) is a partial order where every chain has a least upper bound 
(lub). An admissible predicate P holds for the lub of a chain when- 
ever it holds over the entire chain: Wn.P(x n ) P(\_\ n x n ). A con- 
tinuous function / preserves lubs of chains: f{\_\„x„) = \_\ n f(x„). 



Note also that every continuous function is monotone. A pointed 
cpo (pcpo) or "domain" is a cpo with a least element _L. Ev- 
ery continuous function / on a pcpo has a least fixed-point 
fix(f) = f(fix(f)) = U«/"(^)- I n m i s paper we also use the binder 
notation px.f(x) to denote the least fixed-point of /. 

HOLCF provides a few primitive type constructors, which cor- 
respond to basic domain constructions. First, we have the continu- 
ous function space a — > B, which consists of the continuous func- 
tions from a to B ordered pointwise; this type is used to model 
Haskell's function space. Other constructions include strict sums, 
strict products, and lifting. They correspond to the Haskell datatype 
definitions here: 

data a ®B = SLeft \a \ SRight \B 
data a®B = SPair la \B 
datao-x — Lift a 

Note that the constructors for a®B and a® B are strict, but the con- 
structor for type a_\_ is non-strict: Lift _L / _L. Finally, HOLCF pro- 
vides the type 1, with two elements this models Haskell's 
unit type (). 

2.1 The Domain package 

Constructing recursive datatypes is one important application of 
domain theory. In HOLCF, user-defined recursive datatypes can be 
specified using the Domain package 1 5 1. It can model many of the 
same datatypes that we can define in Haskell, e.g., lazy lists: 

data List a = Nil \ Cons a (List a) 

Given this datatype specification, the job of the Domain package is 
to construct a solution to the corresponding domain equation. 

Lista = \®(a L ®(Lista) L ) (1) 

Since Isabelle 2011, the Domain package is completely defini- 
tional: It explicitly constructs a solution to this equation and defines 
List a without introducing any new axioms |5|. In addition to the 
type itself, the Domain package also defines the constructor func- 
tions and several other related constants. It also generates a large 
collection of useful lemmas and rewrite rules, including injectivity 
and exhaustiveness of constructors, and rules for order comparisons 
like this one: 

Cons x xs Cons y ys xtZy A xs C ys (2) 

We also get some induction rules generated for us: Every type 
gets a low-level induction principle in the form of an approximation 
lemma |8|. For polynomial types (i.e., those expressible as a sum 
of products) we also get a high-level induction rule, with cases 
for each constructor plus a case for ±. Induction rules for lazy 
datatypes have an admissibility side-condition. 

admissible(/ > ) 
P(_L) P(Nil) \fx xs. P(xs) P(Cons x xs) 

Vxs. P(xs) " (3) 

The Domain package can handle any datatype expressible in 
Haskell — subject to the limitations of Isabelle's type system, of 
course. It supports both strict and lazy constructors, mutual recur- 
sion, indirect recursion, and even negative recursion. 

data StrictList a = SNil \ SCons a ! (StrictList a) 
data Indirect a = Leaf a \ Node (List (Indirect a)) 
data Neg = App Neg Neg \ Lam (Neg — > Neg) 

For formalizing Haskell record definitions, it also conveniently 
supports selector functions for constructor arguments. 



2.2 Notation 

We avoid using Isabelle notation as much as possible, favoring a 
Haskell-style syntax for datatype and function definitions. We also 
use Haskell-style notation (...)=>... for class constraints on type 
variables. Isabelle's syntax follows Standard ML in writing type 
constructors postfix; however, for consistency we use Haskell-style 
prefix type application throughout. Isabelle type constructors with 
multiple arguments are shown as tupled. 

We consistently use Greek letters a, /?, y for type variables 
of kind *, and r for kind * — > *. Latin letters a,b,c are program 
variables, with /, g, h, k referring specifically to functions. We often 
use sub- and superscripts to annotate polymorphic functions with 
their types; e.g., fmap T a ^ means ftnap :: (a — > p) — > t a — > r p. 

3. Deflation model of types 

HOLCF provides a special domain T> whose values are deflations, a 
certain kind of idempotent functions. Deflations are used to model 
types: To each "representable" domain type in HOLCF, we asso- 
ciate a representation of type T>. The primary reason for having 
this model in HOLCF is to implement the Domain package: The 
deflation model of types lets us reason about the existence of so- 
lutions to domain equations, because we can construct recursively 
defined deflations to represent them. 

The Tycon library takes advantage of this existing model of 
types to derive further benefits. The deflation model gives us a 
way to express the relationship between different type instances 
of polymorphic functions, letting us reason about polymorphism. 
It also lets us reason about type quantification, by quantifying over 
deflations. 

In the remainder of this section, we describe the underlying 
concepts behind the deflation model, as well as its implementation 
in HOLCF. 

3.1 Embedding-projection pairs and deflations 

Some epos can be embedded within other epos. The concept of an 
embedding-projection pair (often shortened to ep-pair) formalizes 
this notion. 

Definition 1. Continuous functions e :: a — > p and p :: p — > a 
form an embedding-projection pair (or ep-pair) if poe = id a and 
eo p\Z idp. In this case, we write (e,p) :a% p. 

Ep-pairs have many useful properties: e is injective, p is surjec- 
tive, both are strict, each function uniquely determines the other, 
and the image of e is a sub-cpo of p. The composition of two ep- 
pairs yields another ep-pair: If (e\ , p\ ) : a H> ft and [e%, P2) '-P^y, 
then {ei°e\,p\op2) : or -§7. Ep-pairs can also be lifted over many 
type constructors, including strict sums, products, and continuous 
function space. 

Definition 2. A continuous function d :: a — > a is a deflation if it 
is idempotent and below the identity function: do d = d C id a . 

Deflations and ep-pairs are closely related. Given an ep-pair 
(e, p) : a P, the composition e o p is a deflation on p whose 
image is isomorphic to a. Conversely, every deflation d :: p — > p 
also gives rise to an ep-pair. Let the cpo a be the image of d; also 
let e be the inclusion map from a to p, and let p = d. Then (e,p) is 
an embedding-projection pair. So saying that there exists an ep-pair 
from a to p is equivalent to saying that there exists a deflation on 
p whose image is isomorphic to a. Figure [T] shows the relationship 
between ep-pairs and deflations. 

A deflation is a function, but it can also be viewed as a set: 
Just take the image of the function, or equivalently, its set of fixed 
points — for idempotent functions they are the same. The dashed 
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Figure 2. Embedding-projection pairs provided by the universal 
domain library in HOLCF 

outline in Fig. [T] shows the set defined by the deflation d. Every 
deflation on a cpo a gives a set that is a sub-cpo, and contains _L 
if a has a least element. Not all sub-epos have a corresponding 
deflation, but if one exists then it is unique. The set-oriented and 
function-oriented views of deflations also give the same ordering: 
For any deflations / and g, f C g if and only if Im(/) C Im(g). 

3.2 Representable types 

We say that a type a is representable in domain U if there exists 
an ep-pair from a to U, or equivalently if there exists a deflation 
d on U whose image Im(rf) is isomorphic to a. We say that U is a 
universal domain for some class of epos if every cpo in the class 
is representable in U. Isabelle/HOLCF provides such a universal 
domain type U, which can represent any bifinite domain — this is a 
large class of epos that includes (but is not limited to) all Haskell 
datatypes j4J- 

HOLCF defines an axiomatic class of representable domains. 
The class fixes operations emb and pray, and assumes that they form 
an ep-pair into the universal domain. 

class Rep a where 

emb :: or — >• U 
proj ::U —¥ a 

proj o emb = id a 
emb o proj C idjj 

The universal domain type itself is trivially representable, using 
identity functions. For other base types like 1, the HOLCF universal 
domain library provides appropriate ep-pairs (Fig.[2j. 

instance Rep U where instance Rep 1 where 

emb = idu emb = in\ 

proj = idu proj = out\ 

HOLCF defines the domain T> of deflations over the univer- 
sal domain as a subtype of U —¥ U. (In the Isabelle formalization, 
explicit conversions between types T> and U — > U are always re- 
quired, but we will keep those implicit here.) 

typedef V = {d::U -^U\dod = d\Zid u ) (4) 

Definition 3 (Representation of a type). Given any representable 
type a, we can construct its representation (a deflation of type T>) 
by composing emb and proj. We denote the mapping from types to 
deflations as follows: 

\a\ = f emb a o proj a 

Note that the representation of the universal domain \LA\ is 
therefore the identity deflation, which is maximal among all de- 
flations. Thus we have \a\ C \U\ for all representable types a. 

3.3 Representable type constructors 

While types can be represented by deflations, type constructors 
(which are like functions from types to types) can be represented 
as functions from deflations to deflations. We say that a type con- 
structor F ::*—>* is representable in U if there exists a continuous 
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function F V ::V^V such that [F(or)] = F v [or]. Such deflation 
combinators can be used to build deflations for recursive datatypes 
(2] §7]. This is precisely the technique used by recent versions of 
the Domain package 1 5 , §6.6]; we will also use the same technique 
for creating new type constructors in Sec. [5] 

We have a recipe for setting up a primitive HOLCF type as a 
representable type constructor: We just need an ep-pair to the uni- 
versal domain and a map function. (The HOLCF universal domain 
library provides a selection of suitable ep-pairs; see Fig.|2]) We now 
demonstrate the recipe using the strict product type. 

map® :: (a -> a',/3 -> 0) -> a®/3 -> a'®0 
map® (f,g) (SPairxy) = SPair(fx) (gy) 

a ®x> b = in® o map® (a,b)o out® 

instance (Rep a, Rep 0) => Rep (a®0) where 
emb = in® omap® (emb a ,embp) 
proj = map® (proj a ,proj p ) ° out® 

The reader can verify that (®x>) does in fact preserve deflations, 
that emb and proj do form an ep-pair for type a ® /?, and that 
(®d) actually does represent the strict product type constructor: 

Most other HOLCF type constructors work exactly like the 
strict product. However, the continuous function space is special 
because it is contravariant in its first argument. 

map^ :: (a' -> a,ft -> 0) -» (a -> -> (a' -} 0) 
map^f (f,g)h = gohof 

(->Z>) ::V^V^V 

a—¥-E>b = o map-,, (a, b) o out^ 

instance (Rep a, Rep 0) =>• Rep (a — > 0) where 

emb = in-,, omap^ (proj a ,embp) 
proj = map^ (emb a ,projp) oout~> 

Due to contravariance, the first argument to map_> has type of— la 
instead of a — > a 1 . Also note that in the Rep instance, emb calls proj 
and vice versa. Otherwise everything works similarly to the other 
types. 

3.4 Coercion 

We can write a function to coerce between any two representable 
types: First embed into the universal domain U, and then project 
out to a different type. 

coerce :: (Rep a, Rep =?a — > /J 
coerce a p = projp o emb a 

Our primary use for coercion will be to relate different type 
instances of polymorphic functions. In the remainder of the paper, 



we will often need to prove properties about coerced values; to 
facilitate this, we assemble a collection of simplification rules. First 
of all, coerce may reduce to emb, proj, or id, depending on the type: 

coerce a & — id a (5) 
coerce a u = emb a (6) 
coerce u , a =proj a (7) 

Other properties about coerce depend on the relative "sizes" of 
the source and target types. A coercion from a smaller to a larger 
type is injective (an embedding, in fact). Coercing twice in a row is 
the same as coercing once, as long as the intermediate type is larger 
than one of the source or target types. 

M Ejglv M E M 

coercep^, o coerce a ^ = coerce a ^ 

Coercing between similar datatypes is the same as mapping 
coerce over the elements. (As an exercise, the reader may wish to 
verify Eq. |5) by expanding the definitions given earlier in Sec. |3.3| ) 
Using these rules, it is easy to verify that coerce commutes with 
each data constructor. 

coerce a ®p, y ®5 = map® (coerce a ^ y ,coercepj) (9) 
coerce a ®p t y®g = ]nap l ^,(coerce a ^,coercep^) (10) 
coerce ait p ± = map ^(coerce a ^p) (11) 

A similar rule holds for coercions between two function types. 
The expanded form in Eq. will be particularly useful for 
simplifying coercions in later proofs. 

coerce ( a ^p\(y_^g\ = map^(coerce y , a ,coercep^) (12) 

coercef a _ > 0\iy^g'j f = coercepgo f o coerce y , a (13) 

A note about the ubiquity of the Rep class: For the remainder 
of this paper, we will assume that all types a,f},y,... are in class 
Rep, without writing Rep class constraints explicitly. The reader 
may treat emb, proj, and coerce as if they were completely poly- 
morphic. (HOLCF achieves a similar effect using the "default sort" 
mechanism, assigning all type variables to class Rep unless anno- 
tated otherwise.) 

4. Type constructor classes in the Tycon library 
4.1 Class Tycon and type application 

In the Haskell type expression to, the two type variables have 
different kinds: Say a is an ordinary type of kind *; then t may 
be a type constructor of kind * — > *. Isabelle's type system was 
not designed to be this expressive: All type variables in Isabelle 
represent ordinary types (corresponding to Haskell kind *). 

Our solution to this limitation (originally introduced in (7)) is 
to define a binary Isabelle type constructor (— • — ) that models 



Haskell type application. The right argument must be in the Isabelle 
class Rep, which models Haskell kind *. The left argument must be 
in a new class Tycon, which models Haskell kind * — > *, 

Class Tycon is defined as follows. It has no axioms, but fixes a 
single constant which is a deflation constructor]^] 

class Tycon r where |t|} :: V — > V 

Now we want to define type r ■ a so that [t • a] = |r|}|a]. We 
therefore define r ■ a as a subtype of U, consisting of the image (or 
equivalently, the set of fixed-points) of the deflation {|T|}|ffJ. 

typedef ( Tycon r, Rep a)=^r-a 
= {u::U\ HW« = »} 

instance {Tycon t, Rep a) => Rep (t • a) where 

emb x = x 
proju = \T\{a\u 

Note that the definitions of emb and proj contain implicit coercions 
between U and t • a. The desired representation property then 
follows directly from the definitions of emb and proj: 

[t'«]=|#] (14) 

It is worth pointing out that while the construction refers to 
the deflation combinator \t\, actual values of type r are never 
used anywhere. This is consistent with Haskell, where there are 
no values inhabiting higher-kinded types. 

4.2 Class Functor 

The Haskell Functor class is for types that can be mapped over. 

class Functor r where 
finap :: (a — > fS) — > (ret — > t/3) 

Each Haskell Functor instance should satisfy the identity and com- 
position laws: 

finap id = id (15) 
finap (fog)= finap f o finap g (16) 

How close are we to being able to formalize this in Isabelle? 
Using the type application machinery from Sec. |4.1| we can at least 
express the class constraint Functor t and the result type of finap. 
However, there are still some problems. First, let us examine the 
type of fmap more closely. The type constructor variable t is fixed, 
but types a and ft are actually universally quantified: 

fmap T :: Vff/?. (a— >{S) — > (r-a— >t-0) 

The problem is that Isabelle's class system does not allow poly- 
morphic class constants. Isabelle's type system does not support 
first-class polymorphism, and the type of class functions are only 
allowed to contain one free type variable, i.e., the one mentioned in 
the class constraint 1171 . 

The solution is to move the polymorphism out of the class decla- 
ration. We replace the polymorphic finap 7 with a single, monomor- 
phic constant representing finap 7 uu , the "largest" type instance 
of finap 7 . (We use the underlined name fmap 1 to refer to this 
monomorphic version.) We then define the polymorphic fmap 7 by 
coercion from finap 7 . 

class ( Tycon t) => Functor r where 
finap 7 ::(U^U)^(t-U^t-U) 

fmap :: (Functor t) => (a — > /?) — > r ■ a — > r ■ [} 
fmap 7 a p = coerce fmap 7 

1 In the Isabelle formalization, we express the dependence of \t\ on type 
r by adding a dummy function argument whose type is a phantom type 
mentioning r. 



In Haskell, polymorphically typed functions like fmap 7 are al- 
ways parametrically polymorphic. That is, parametricity (a meta- 
property of the type system) ensures that all of the different type 
instances of fmap 7 , ^ behave uniformly 1 16 1. Isabelle's type system 
does not provide any automatic parametricity guarantees, but by 
defining all type instances of finap 7 by coercion from a single con- 
stant, we ensure a similar kind of uniformity across type instances 
in the our library. 

The formalization of class Functor is yet incomplete: We have 
the constant, but not the functor laws. We need to find a set of class 
axioms about fmap 7 that will let us derive the polymorphic functor 
laws about fmap 7 . 

As a first try, we might just write down the functor laws with all 
the types specialized to type U : 

fmap 7 id u = id T . u (17) 

finap T (f°g) = finap 7 fo finap 7 g (18) 

However, we shall treat these as tentative until we see whether they 
are sufficient to derive the polymorphic functor laws. 

Theorem 1 (Identity). For any r in class Functor and repre- 
sentable type a, the functor identity law holds: 

f ma P T a,a id a = td T -a 

Proof. We start by unfolding the definition of finap and rewriting 
with properties of coerce. 

fmap 7 a a id a 

= (coerce finap 7 ) id a 

— coerce^.y T . ff j o fmap 7 (coerce id a ) o coerce^. a T .^j 

= coerce ( T . w>T . a ) o finap 7 \a\o coerce (T . a T . u) 

At this point we are stuck. A law about fmap 7 idy does not help 
here, because coercing id a to type U — > U does not yield idy; it 
gives [a] instead. What we really need is a rewrite rule for fmap 7 
applied to an arbitrary deflation. The class axiom must assert that 
the map function fmap 7 "agrees" with the deflation combinator |t| 
in a certain sense. 

Definition 4. We say that a function / on a representable type a 
agrees with a deflation d on the universal domain, if / coerced to 
type U — > U is equal to d (regarded as a function). 

(/ :: or a) lh (d :: 23) emb a °f°proj a = d 

This agreement relation is already present in HOLCF: It is used in- 
ternally by the Domain package for relating deflation combinators 
to map functions, for proving identity laws and deriving induction 
rules 1 5 1 . So it is fitting that it should appear in this situation, where 
we are again proving functor identity laws. 

We replace Eq. |T7} with this generalized class axiom, shown 
here also in its unfolded form: 

finap 7 (d::V)\Y \r\d (19) 
emb rU o finap 7 (d::V) oproj T . u = {t} d (20) 
Now we can continue where we left off: 

coerce {T . U T . a) o fmap 7 la\o coerce {T . a T . u) 
= proj T -a ° emb T-U ° finap T \a\ °proj T . u o emb T . a 
= Prvjr a °M H ° emb T . a 
= proj t- a ° l T ' a \ ° emb T . a 
= proj T . a ° emb T . a ° proj T . a o emb T . a 
= id T . a o id T . a 

= id T . a □ 



Theorem 2 (Composition). For any r in class Functor and func- 
tions f ::/? — > y and g :: a — > [3, the functor composition law holds: 

fmap T a y (fog)= fmap 1 ^ f o fmap T a p g 

Proof. We rewrite both sides of the equation, trying to reduce it to 
a trivial equality. We start by unfolding the definition of finap. 

finapl.y (f°i)= fi na Pp,y f ° finapl,? 8 
(coerce fmap T )(f o g) = (coerce fmap T ) f o (coerce finap 1 ) g 

After rewriting using Eq. \13) , we have 

coerce o finap (coerce (/og))o coerce 

= coerce o fmap 1 (coerce f) o coerce 

o coerce o fmap 1 (coerce g) o coerce 

In the middle of the right-hand side we have two adjacent 
coercions, where we go from type r • U to r • /? and back. Since 
the intermediate type t -fj is smaller, they do not cancel completely. 
It turns out that they reduce to an application of fmap T : 

coercej.p^.u o coerce T . U j .p 

= P r °j T u ° embr.fi oproj T .p o emb T . u 

= proj T .u ° fr -Pi ° emb T . u 

= proj T . u "Hi" emb T . u 

=Proj T .u ° emb T . u o fmap 1 \0\ oproj T . u oemb T . u 

= id T . u o fmap T \fi\ o id T . u 

= fmap T \P\ (21) 

Rewriting the right-hand side with Eq. \2\) yields three occur- 
rences of fmap T composed together. Using the composition rule 
(T8) to collapse these, we get 

coerce o fmap 1 (coerce (f o g) ) o coerce 

= coerce o fmap 1 (coerce f o [[/?] o coerce g) o coerce 

Finally, it only remains to show that the arguments to fmap 1 on 
each side are equal. We work from right to left. 

coerce {fi ^ y)Au ^ u) f 'o lffl ocoerce (a^p),(U^U)8 
= emby o / oprojp o \p\ o embp o g oproj a 
= emby o f o projp o embp o projp o embp o g oproj a 
= emby ofo idp o idp ago proj a 
= embyo fogoproj a 

= coerce (ff _> r ),( W _> W ) (/ °g) □ 

The final formulation of class Functor, complete with the gen- 
eralized identity law, is shown in Fig. [3] 

We should note that while transfer proofs like Theorem [2] may 
look lengthy on paper, they are actually highly automated in Is- 
abelle: Most such proofs require only a single call to Isabelle's sim- 
plifier, as long as the appropriate extra rewrite rules like Eq. \2l \ are 
in place. This is important for usability of the library, because users 
will need to perform similar transfer proofs often — not just when 
defining new constructor classes, but also when instantiating them. 

We present proofs here in a point-free style, with liberal use 
of the function composition operator (o), because it makes the 
proofs easier to read. However, Isabelle is not so good at reason- 
ing modulo the associativity of function composition. Automatic 
proofs by rewriting work better with nested function applications, 
e.g. f(g(h(x))) rather than fogoh. Therefore, the rewrite rules and 
other theorems in our library are actually formalized using fully ap- 
plied functions instead of function composition. 



class ( Tycon r) => Functor r where 
finap 1 :: (U^U) -> (t-U^t-U) 

fmap 1 (d::V)\\- jr^d 

fmap 1 (fog) = fmap 1 fo fmap 1 g 

finap :: (Functor t) =$-(a— > /3) — > T ■ a — > T-/3 
finap T a p = coerce fmap 1 



Figure 3. Isabelle Functor class 

4.3 Generic theorems about functors 

Now that we have a functor class, we can prove further theorems 
about fmap. Here is an example theorem, about its strictness. The 
proof uses only the functor laws and basic properties of domain 
theory; the result is applicable to any valid functor instance. 

Theorem 3 (Strict fmap). If f :: a — > fJ is a strict function, then 
finap f is also strict: f _L = _L fmap f _L = _L. 

Proof. Fix / :: a — > f}, and assume / J_ a = _L^. Let g :: fj a be 
the constant bottom function, gx = _L a . From the strictness of /, it 
follows that fog = const A. C idp. We can now show the goal by 
antisymmetry and transitivity reasoning: 

finap f -L C fmap f ( fmap g _L) {monotonicity with _L} 

= fmap(fog)J_ {composition law} 

C fmap id J_ {monotonicity, / o g C id} 

— ± {identity law} 

Thus we have finap which implies fmap f _L = _L. □ 

4.4 Subclasses of Functor 

Users of the Tycon library can easily formalize additional construc- 
tor classes that are subclasses of Functor. The library already con- 
tains several examples, and they all follow the same general pro- 
cess. 

A constructor class may fix some number of polymorphic con- 
stants, and assume a set of polymorphic class axioms. The formal- 
ized constructor class fixes a monomorphic version of each poly- 
morphic function, with type variables instantiated to U. Similarly, 
the formalized class assumes a monomorphic version of each class 
axiom. The polymorphic version of each functions is defined sep- 
arately, using coercion. In general, we will also add a naturality 
law for each polymorphic function, which is related to the para- 
metricity property, or free theorem, derived from its type 1 16 1. The 
naturality laws are necessary for transferring properties about the 
monomorphic constants to the polymorphic ones. 

The Functor class is a special case: No extra naturality law 
was needed for fmap, because the functor composition law is the 
naturality law for fmap. The Monad class is perhaps the primary 
motivation for this work, but the interactions and redundancies 
between its laws also make it a bit of a special case. The general 
principles are best illustrated with a more regular example. So 
here we present a class FunctorPlus, which fixes a binary append 
operation for combining functor values: 

class (Functor t) => FunctorPlus t where 

(-H-) ::Ta->ra->Tff 

Each instance of FunctorPlus should also ensure that (H+) is asso- 
ciative: 

(x-H- y)H+z = xH+(y+fz) (22) 
Any implementation of (+(-) should also satisfy a naturality 
condition, which essentially states that it commutes with fmap. The 



class (Functor t) => FunctorPlus r where 
(H+ T ) v.t-U^t-U^t-U 

fmap T /(xj+ T y) = (fmap 7 f x) ±j- 7 (finap 7 fy) 
(x 4f T y) J+ T z = x +h T (>' +h T z) 

(+(-)« (FunctorPlus T)=>T-a^r-a^T-a 
(-H-o) = c^ce (d+ T ) 



Figure 4. Isabelle FunctorPlus class 

form of this law is derived from the polymorphic type of (-H-); it 
holds in Haskell as a consequence of parametricity. 

finap f(x-^y) = (fmap fx) H+ (finapfy) (23) 

We formalize class FunctorPlus in Isabelle according to the 
general pattern outlined above; the code is shown in Fig. [4] 

The need for the naturality law becomes apparent when trans- 
ferring laws to the polymorphic version of (H+). When we transfer 
the associativity law, we get a situation similar to what we had with 
the proof of Theorem|2] Between the two occurrences of (-H-), we 
get a pair of coercionsfrom r-U to r ■ a and back; these reduce to 
finap 7 [or] . The naturality law lets us push the fmap T into the ar- 
guments of the inner append, bringing the two appends together so 
that the monomorphic associativity rule can be applied. In the end, 
we are able to prove the polymorphic version of the associativity 
law with one call to the simplifier. Similarly, we can also derive the 
polymorphic version of the naturality law in one step. 

4.5 Class Monad 

The definition of the Monad class should be familiar to every 
Haskell programmer. 

class Monad t where 
return : : a — > ra 
(»=) :: r a — > (a — > r 8) — > r B 

The standard monad laws are left unit, right unit, and associativity. 

return a »= k = ka (24) 

m s== return = m (25) 

(ms=A)s=A; = m»=(/lx./ix»=fc) (26) 

To translate this Haskell class definition into Isabelle, we can 
follow the standard process established in Sec. |4.4| Replace the 
polymorphic operations with monomorphic ones, where each type 
variable is instantiated to U ; specialize the types in the class axioms 
to U ; and add naturality laws for each of the constants. 

Below are the naturality laws for the monad operations, derived 
from their type signatures. Note that (»=) has two naturality laws, 



because its type has two polymorphic variables. 

finap /(return a) = return (fa) (27) 

(finap f m)»=k = m?n= (ko f) (28) 

fmap f (m »= k) = m » (fmap fok) (29) 



Three monad laws plus three naturality laws would make six 
class axioms in total. However, it is possible to reduce this number. 
Using Eqs. {25\ and j28[ >, we can derive a simple definition of finap 
in terms of (»=) and return: 

fmap fm = m »= (return o /) (30) 

This definition of fmap is often referred to as a fourth monad law; 
it is expected to hold for any Haskell type that is an instance of both 
the Functor and Monad classes. 



class (Functor r) => Monad r where 
return 7 v.U —¥T-li 
(^ T ) ::t-U^(U^t-U)^t-U 

return T u a= T k =ku 

(m » T h) = m»= T (Ax. h x »= T k) 

finap T fm =m »= T ( return 7 o f) 

return : : (Monad t) => a — > r ■ a 
return 1 , = coerce return 7 

(»=) :: (Monad t) => T • a (a — > T ■ 0) — > T ■ j3 
(=Kv,,e) = c ° erce (=^ T ) 



Figure 5. Isabelle Monad class 

It is simple to verify that from Eqs. {14) , |26j, and l |30| >, we can 
derive all of the other monad and naturality laws. Thus we can use 
these three to formalize our Monad class (see Fig. [5}. 

From the class axioms, we re-derive the rest of the original six 
laws for the monomorphic constants. Then we transfer all of the 
laws to the polymorphic constants, using the automated method 
described previously in Sec. |4.4| 

4.6 Generic theorems about monads 

Using the polymorphic monad laws, we can proceed to prove fur- 
ther theorems about arbitrary monads — for example, a property 
about the strictness of the bind operator. 

Theorem 4 (Strict »=). Bind is strict in its first argument, if its 
second argument is also strict: kl. = _L ==> _L S> k = _L. 

Proof. By antisymmetry, it suffices to show _L » k C J_. 

_L »= k C return _L »= k {monotonicity} 
= kA. {left unit law} 

= ± {strictness of k} □ 

Within the context of class Monad, we can also define derived 
monadic constants, such as join. 

join :: (Monad r)=t-r-(T-a)—¥r-a 
join m = m »= id 

We can derive a collection of standard lemmas about join by un- 
folding its definition and rewriting with the monad laws. These 
lemmas will then be valid for any type in the Monad class. 

5. Instantiating type constructor classes 

Type constructor classes like Functor and Monad are already useful 
on their own: For example, we can use them to formalize generic 
Haskell monadic operations like sequence and foldM, and prove 
properties about them. Using the ordinary HOLCF Domain pack- 
age with the right class constraints, we can also define higher-order 
type constructors: 

data Tree(r,a) = Tip | Nodea(r- (Tree(r,a))) 

This is good, but sooner or later, we will want to populate our 
constructor classes with some concrete instances. To show how a 
Tycon library user can define new functors and monads, we will 
now demonstrate the process with a recursive lazy list datatype. 

data List a = Nil \ Cons a (List a) 

The Domain package can handle this definition with no trouble. 
However, we do not want List to be an ordinary Isabelle type 



constructor, which can only appear in fully applied form. We want 
List as a first-class type constructor, i.e., an instance of class Tycon. 
We really want to write this definition instead, which uses the type 
application operator: 

data List ■ a = Nil | Cons a (List ■ a) 

The Tycon library now provides full automation for such type 
definitions, in the form of a new user-level type definition com- 
mand. It works much like the HOLCF Domain package, and is im- 
plemented using much of the same code. 

The process by which the Domain package defines new datatypes 
can be broken down roughly into four steps: 

1. Define a deflation combinator, and use it to define a repre- 
sentable domain satisfying the domain equation. 

2. Define constructors and related functions; generate theorems. 

3. Define take function; derive induction rules. 

4. Define map function; relate it to the deflation combinator. 

Defining a usable Tycon involves essentially the same four steps. 
However, some of the steps are adapted slightly to deal with the 
Tycon instance and the type application operator. We now describe 
how our new command completes each of the four steps to make 
List into a Tycon and Functor. 

1 . Just like the Domain package, it constructs a deflation as a least 
fixed-point, based on the recursive domain equation. However, 
instead of defining a type List a directly from this deflation, it 
defines List as a singleton type, and makes it an instance of class 
Tycon. The constructed deflation is used to define JZiitJ-. 

\List\(a) = (jit.lv®v ®X>'±J) (31) 
{List- a] = [10 (ai <g> (List-a) ± )] (32) 

By unfolding the fixed-point, the desired domain equation (32} 
is derived. It then follows that the coercions absList and repList, 
defined as shown here, form an isomorphism. 

absList a = coeKe^^^-a^test-a) 
repList a = coerce^.a^a^ust-a)^) 

2. Using these isomorphism theorems, a component of the Do- 
main package is called to generate the multitude of definitions 
and theorems related to the constructors Nil and Cons. This step 
works exactly the same as with ordinary domain definitions. 

3. A call to another Domain package component generates a chain 
of listTake functions: 



listTake :: Nat 
listTake 
listTake (n + 1 ) 
listTake (n + l) 



-» List ■ a —, 

xs 

Nil 

(Cons x xs) 



List ■ a 
= ± 
= Nil 

= Cons x (listTake n xs) 



By reasoning about the deflation agreement relation (lh), we 
can show |J n listTake n = id from the definitions of listTake and 
the deflation combinator. From this, the approximation lemma 
1 8 1 and induction rules are then derived, just as they are in the 
Domain package. 



id a ih h 
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coerce o / o coerce a £ lh d 

Alhdj f 2 \Yd 2 



mo-PAf) ll_ ( d ±c) map (B (f 1 ,f 2 ) ^ (d\ ®v> d 2 ) 

fthdi f 2 \\-d 2 fH-d 
map<g>{fl>h) ll_ {d\ ®T>d 2 ) fmap 1 '/lh \r\d 

Figure 6. Agreement rules between map functions and deflations 

The Functor class requires a proof of the agreement law 
finap Llst d lh \List\d. Because the definitions of fmap L,st and 
•jL/i/^ have the same structure, the proof can be discharged us- 
ing a collection of structural rules, some of which are listed in 
Fig. [6] The Domain package maintains this list of rules for use 
in its own internal proofs {5\ §6.6]. 

It is not always possible to automatically prove the functor com- 
position law: For some strict datatypes, the composition law can 
fail when used with non-strict functions. To avoid this difficulty, 
we split off a separate Prefunctor superclass that asserts only the 
identity law. Our new command can then always succeed in gen- 
erating a Prefunctor instance for each new datatype; we leave it to 
the user instantiate the Functor class by proving the composition 
law separately. 

For the List type constructor, composition can be proved using 
the ordinary HOLCF technique of induction over the datatype. 

Further class instantiations. Compared to Tycon and Functor, 
instantiations of subclasses like FunctorPlus and Monad are rel- 
atively straightforward. We write definitions of (+h), return , and 
( »= ) using ordinary user-level methods: the standard Isabelle def- 
inition command for non-recursive functions, and the HOLCF 
Fixrec package |5| for the recursive ones. The class axioms for 
these subclasses are all ordinary equations, so they can be proved 
using ordinary techniques like induction. 

Transferring theorems. We now have a type constructor List with 
instances of the Functor, FunctorPlus, and Monad classes. This 
means that we can use the polymorphic functions fmap, (+h), 
return, and (»=) at type List ■ a. We can also apply any generic 
theorems from those classes to the List type. 

However, we do not have any LLs?-specific theorems about the 
polymorphic functions yet. For example, if Cons x xs +h ys = 
Cons x (xs j+ys) is one of the defining equations for (+h), we 
should like to have a version of this theorem for (+h) as well. 

To obtain the polymorphic versions of such lemmas, we need to 
do a transfer process, much like we did with Theorem[2]and for the 
class axioms in Sec. |4.4| The proofs can generally be completed 
with one call to the simplifier, using a collection of simplification 
rules for coercions. To transfer theorems that mention Nil or Cons, 
we must first prove some additional simplification rules stating that 
coerce commutes with those data constructors. These proofs are 
also simple, and potentially could be generated automatically. 



4. The final step is to instantiate the Functor class. The fmap 6. Verifying monad transformers 



function is defined in a stylized way, which exactly matches 
the structure of the definition of jZisfJ-. 

fmap L ""f = (pt.absListo 

mapg,(idi,map^(map± f,map± ?)) o repList) (33) 

The Domain package would normally generate the same defini- 
tion, but would define it as a separate constant mapList. 



In addition to simple type constructors like List, the Tycon library 
can also be used to define Tycon instances with additional type 
parameters, some of which may be type constructors themselves. 
In particular, this means that we can define a monad transformer — 
i.e., a monad that is parameterized by another inner monad. 

The resumption monad transformer was covered in our previous 
work 1 7 1, but we have some improvements here. With the improved 



data ResT ra = Done a \ More (r (ResT r a)) 

instance (Functor t) =>• Monad (ResT t) where 
return x = Done x 
Done x J8*= k = k x 

More m 3= k = More (ftnap (Ar. r »= k) m) 



Figure 7. Haskell definition of ResT monad transformer 

class definitions and better proof automation, we can now prove 
more with less effort: In addition to instantiating the monad class, 
we also proceed to define an interleaving operator and prove laws 
about it. 

The new automation provided by the Tycon library has made it 
easier to test out definitions of new type constructors. Experimenta- 
tion with the error and writer monad transformers has revealed that 
neither one truly preserves the monad laws. However, we have also 
found that the monad laws for both of those types actually are pre- 
served for values constructible from standard operations. That is, it 
is possible to view each as an abstract datatype whose operations 
maintain an invariant; in this abstract view, each one actually does 
form a lawful monad. 

6.1 Resumption monad transformer 

The resumption monad transformer [ 14 1 augments an inner monad 
with the ability to suspend, resume, and interleave threads of com- 
putations. The Haskell definitions for the resumption monad trans- 
former are shown in Fig. [7] (Note that although we call it a monad 
transformer, the Monad instance only requires t to be a functor.) 

The constructor Done x represents a computation that has run 
to completion, yielding the result x. More c represents a suspended 
computation that still has more work to do: When c is evaluated, 
it may produce some side effects (according to the monad t) and 
eventually returns a new resumption of type ResT r ■ a. Resump- 
tions are a bit like threads in a cooperative multitasking system: A 
running thread may either terminate (Done x) or voluntarily yield 
to the operating system, waiting to be resumed later (More c). 

We formalize the Haskell type ResT r a as ResT t • a in our 
library. The type constructor definition generates an fmap function 
satisfying these rules: 

fmap f (Done x) = Done ( f x) 

fmap f (More m) = More (fmap ( fmap f) m) 

From the low-level principle of take induction, we derive a high- 
level induction rule for type ResT r-a: 

admissible(P) Mx.P(Done x) 
P(l) Mmf. (Vr.f (/>)) =» P(More (fmap f m)) 

Vr.P(r) ( ' 

We then proceed to instantiate the Monad class for ResT t; the 
proofs of the monad laws are all proved using the high-level in- 
duction rule. With this class instance, we have shown that ResT is 
a valid monad transformer. 

Some new features of our library are nicely demonstrated by the 
definition and verification of an interleaving operator for resump- 
tions 1141 . The Haskell definition can be seen in Fig. [8] If both 
arguments are Done, then we combine the results and terminate^] 
While either argument is More, we nondeterministically choose one 
such argument, run it for one step, and then recurse. Note that the 
definition uses a FunctorPlus class constraint — a type class whose 
formalization was made possible by the new Tycon library. 

2 We combine the results with function application so that we get an applica- 
tive functor; in other contexts a pair constructor might make more sense. 



(©) :: (FunctorPlus t) 

ResT T (ot — y 0) — ^ ResT ra^ ResT r fj 
Done f ® Done x = Done (f x) 
Done f © More v = More ( fmap (Ar. Done f®r)v) 
More u ®Done x = More (fmap (Ar. r®Done x) u) 
More u © More v = More (fmap (Ar. More u®r)v 
M-fmap (Ar. r® More v) u) 



Figure 8. Haskell definition of interleaving operator for ResT 



data Error s a = Err s \ Ok a 

instance Functor (Errors) where 
fmap f (Err e) = Err e 
fmap f (Ok a) = Ok (fa) 

instance Monad (Errors) where 
return a = Oka 
Err e 3= k = Err e 
Ok a »= k =ka 



Figure 9. Haskell definition of Error monad 



ne wtype ErrorT et a = ErrorT { runET : : r (Error ea)} 

instance (Monad t) => Functor (ErrorT et) where 
fmap f (ErrorT t) = ErrorT (fmap ( fmap f) t) 

instance (Monad t) => Monad (ErrorT e t) where 
returna = ErrorT (return (Ok a)) 
m»=k = ErrorT (runET m^= An. 

case n of Err e — > return (Err e) 
Oka^r runET (ka)) 



Figure 10. Haskell definition of ErrorT monad transformer 

It turns out that (©) satisfies all the laws of an applicative 
functor 1 1 1 1. The trickiest to prove is the associativity law: 

Done (o)®u®v®w = u®(v®w) (35) 

The proof proceeds by nested inductions on u, v, and w, sub- 
proofs for the non-trivial cases rely on the naturality and associa- 
tivity laws from the FunctorPlus class. A formalization of the same 
theorem was presented in the author's Ph.D thesis (5), although 
there it was defined with a fixed inner monad. This version is more 
general and more abstract. We assume exactly what we need to 
about the type constructor t, nothing more. 

6.2 Error monad transformer 

The error monad transformer appears in Andy Gill's mtl library, 
inspired by Jones | 9 1. It is simply a composition of the inner monad 
with an ordinary error monad. The Haskell definition of the Error 
monad that we use is shown in Fig. [9] It is parameterized by an 
extra type e, the type of error values. 

We define an instance Monad (Errors) using the standard pro- 
cedure outlined in Sec. [5] The formal proofs of the monad laws 
proceed as expected. The resulting error monad type satisfies the 
following domain equation: 

{Error e- a] = [e x © orj (36) 



Using the error monad type, we can now proceed to define the 
error monad transformer. We follow the Haskell definitions from 
Fig. [TO] defining ErrorT as a newtype (i.e., a datatype with a single 
strict constructor). 

newtype [Monad r) => Error! '(e, t) ■ a 
= ErrorT { runET :: r ■ (Error s ■ a) } 

The HOLCF error transformer type satisfies the following do- 
main equation. Note that as a newtype, the right-hand side of its 
domain equation is not lifted. 



\ErrorT(s,r) - a] = [r- (Error s- a) 



(37) 



Building an instance of Functor (ErrorT (e,t)) in the standard 
way, we get a definition of finap that satisfies the following rule, as 
we would expect: 

fmap^ ErrorT ^f (ErrorT t) = 

ErrorT (fmap 7 (fmap Ermr ^ f) t) (38) 

Problems with monad instance. Unfortunately, we run into dif- 
ficulty when trying to prove an instance of Monad (ErrorT (s,t)). 
Not all of the class axioms are provable. The Monad class will not 
let us define constants return and (»=) that do not satisfy the laws, 
so instead we define the return and (»=) from Fig. MOlas separate 
constants unitET and bindET. These and other HOLCF definitions 
for the error monad transformer type are shown in Fig. 1 1 1 1 

Using this collection of non-overloaded constants, we can ex- 
amine in detail the situations where the laws fail. In fact, most of 
the expected laws, e.g. the left unit law, do hold in general. All of 
the lemmas shown below can be proven by showing that runET 
applied to each side yields the same value. 

bindET (unitET a) k = ka (39) 

catchET (throwET e)h = he (40) 

bindET (throwET e)k = throwET e (41) 

catchET (unitET a) h = unitET a (42) 

liftET (return 7 a) = unitET a (43) 

liftET (t »= T it) = bindET (liftET t) (liftET o k) (44) 

A more involved proof shows that associativity also holds for 
bindET. 

Theorem 5. The error monad transformer satisfies the monad 
associativity law. 

bindET (bindET m h)k= bindET in (Aa. bindET (h a) k) 

Proof. Let R(k) abbreviate the lambda expression in the definition 
of bindET, so that runET (bindET mk) = runET m'»=R(k). Also 
note that R(k) is strict. The proof then proceeds by applying runET 
to both sides of the equation. After simplification, we have: 

(runET m»=R(h))»=R(k) 

= runET m»=R(Aa. bindET (ha) k) 

After rewriting the left-hand side with the associativity law, both 
sides have the form runET 'm»= / '. It then suffices to show that the 
functions on both sides are equal for all arguments: 

Vx. R(h) x » R(k) = R(Aa. bindET (h a) k) x 

We proceed by cases on x. If x = _L, then using Theorem[4]we see 
that both sides reduce to _L. If x = Err e, then both sides reduce 
to return 7 (Err e). Finally, if x = Ok a, then both sides evaluate to 
runET (ha) »=R(k). □ 

On the other hand, the right unit monad law is not satisfied 
in general. Unless the inner monad r has a strict return function, 
m = ErrorT (return _L) is a counterexample to the right unit law. 
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liftET f e INV 
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Figure 12. Inductive invariant based on ErrorT abstract interface 

Theorem 6. The error monad transformer satisfies the right unit 
law if and only if the inner monad has a strict return. 

(V 'm. bindET 7 m unitET 7 = m) (return 7 _L = _L) 

Proof. Case (=>): If we instantiate m = ErrorT (return _L), then 
the equation reduces to _L = return _L. Case (<*=): As above, let 
R(k) abbreviate the lambda expression in the definition of bindET. 
We proceed to show bindET m unitET — m by applying runET to 
both sides. After simplification, we get: 

runET m »= R(unitET) = runET m 

After expanding the right-hand side with the right unit law, both 
sides have the form runET m »= /. It then suffices to show that the 
functions on both sides are equal for all arguments: 

\/x.R(unitET) x = return x 

If x = _L, then the equation reduces to _L = return _L, which 
we solve by assumption. In case x = Err e or x = Ok a, then the 
equation reduces to a trivial equality. □ 

We could prove a monad class instance for the error transformer 
by creating a subclass for monads-with-strict-return, and putting a 
stronger constraint on type r. 

instance (StrictMonadr) => Monad (ErrorT(s,r)) 

However, this is not very useful in practice, because most monads 
do not have a strict return function (although there are a few that 
do, e.g. the Identity monad and some varieties of powerdomains). 

Data abstraction to the rescue. It turns out that it is impossible 
to construct the offending value ErrorT (return _L) using only the 
standard operations listed in Fig. [TJJ Furthermore, we can show 
that for all values constructible using those operations, the monad 
laws do always hold. This means that when viewed as an abstract 
datatype, we could still consider ErrorT to be a valid monad. 

We define an inductive set INV that includes all values that can 
be constructed with functions in the abstract interface (see Fig.|12}, 
We must also include rules for _L and lubs, to ensure that the set 
INV is a pcpo: In Haskell it is possible to define recursive values 
(i.e., least fixed-points) at any type, abstract or not. 

Finally, we can prove a restricted form of the right unit law by 
induction on INV. The proof is straightforward, and uses techniques 
similar to those used for Theorems [5] and [6] 



m e Inv 



bindET m unitET = m 



(45) 



Besides using an inductive set, there is another, more direct way 
of defining the invariant. We can define INV simply as the set of all 
values satisfying the right unit law: 

INV = { m | bindET m unitET = m } (46) 

It turns out that (Am. bindET m unitET) is actually a deflation, of 
which this version of INV is the corresponding set. (The reader may 
wish to verify that it is idempotent and below id.) 



unitET : : {Monad t) =>• a — > ErrorT (e, t) ■ a 
unitET a = ErrorT {return 7 (Oka)) 

bindET :: {Monad r) =>• ErrorT (e,t) - a— > (a — > ErrorT (e,t) - ft) — > ErrorT (e,t) -p 

bindET mk = ErrorT {runET m s= T A x. case x of Err e — > return T (Err e);Oka^r runET (ka)) 

liftET :: (Monad r) => r ■ a — > ErrorT '(e, r) • a 
liftET t = ErrorT (fmap T Ok t) 

throwET :: (Monad r) =>■ £ — > ErrorT '(e,t) ■ a 
throw ET e = ErrorT (return 7 (Err e)) 

catchET :: (Monad t) ErrorT (e,t) - a— > (s— > ErrorT (e,t) ■ a) — > ErrorT (e,t) ■ a 

catchET mh = ErrorT (runET in :s= T Ax. case x of Err e — > runET (h e);Ok a — > return 7 (Ok a)) 



Figure 11. Isabelle definitions of error monad transformer operations 



class Monoid lo where 
:: to 

(•) :: lo — > — > a; 
data Writer lo a = Result lo a 

newtype WriterT lot a = WriterT {runWT :: r (Writer to a)} 

instance (Monoid u>, Monad r ) => Monad ( WriterT oj t) where 
return a = WriterT (return (Result a)) 
m»=k = WriterT ( run WT m »= A (Result w i a). 

runWT (k a) »= A(Result W2 b). 

return (Result (w\ • Wj) b)) 

tell :: to — > WriterT to r () 

te// w = WriterT (return (Result w ())) 

listen : : WriterT lot a ^ WriterT lot ( Writer oj a) 
listen m = WriterT ( runWT m »= A(Result w a). 

Result w (Result w a)) 



Figure 13. Haskell definition of WriterT monad transformer 

Conveniently, we are already using deflations as our model 
of types. Therefore, we can use this deflation to define a new 
representable subtype of ErrorT (b,t) ■ a that is isomorphic to the 
set INV. The representation of the new type ErrorT' (e,t) ■ a as a 
deflation is therefore as follows: 

\ErrorT 1 (s, t) ■ or] = emb o(Am. bindET m unitET) o pro] (47) 

We have implemented such a type definition using the Tycon 
library, and proven a Monad class instance for it. However, we do 
not yet have a principled technique for transferring definitions or 
theorems between the ErrorT and ErrorT 1 types, so working with 
such subtypes is impractical for casual users. Exploring ways to 
automate this process will be an area for future research. 

6.3 Writer monad transformer 

The writer monad allows a program to output a string (or more 
generally, any Monoid type) along with its ordinary result |9|. The 
bind operation of the monad concatenates the strings output by 
each sub-computation. The writer monad transformer composes 
the writer monad with an inner monad, extending the inner monad 
with a string output capability. The Haskell definitions are shown 
in Fig. [Dj 



The Haskell Monoid class has a set of customary axioms: In- 
stances should ensure that (•) is associative, with as the identity 
element, so0»x = x»0 = x. Note that Monoid is not a construc- 
tor class, so we can formalize it as an ordinary Isabelle type class. 

The formalization of the writer monad transformer works out in 
almost exactly the same way as the error monad transformer: The 
type definitions and Functor instances work fine, but the monad 
instance fails because neither the left nor the right unit law holds 
in general. To reason about return and bind without a Monad class 
instance, we define functions unitWT and bindWT according to the 
definitions in Fig.|13| 

Theorem 7. The writer monad transformer satisfies the right unit 
law if and only if the inner monad has a strict return. 

(Vm. bindWT T m unitWT T = m) <^=> (return 7 A. = AS) 

Proof. Similar to Theorem [6] In the case that return is not strict, 
instantiating m = WriterT (return A.) gives the counterexample. □ 

Theorem 8. The writer monad transformer satisfies the left unit 
law if and only if the inner monad has a strict return. 

(\/xk. bindWT 7 (unitWT x)k = kx) <^ (return 7 1 = _L) 

Proof. Similar to Theorem[7] In case return is not strict, instantiat- 
ing k = Ax. WriterT (return A.) gives the counterexample. □ 

As with the error monad transformer, we can define a subset of 
type consisting of those values that satisfy the right unit law: 

INV = { m | bindWT m unitWT = m } (48) 

It is straightforward to check that all writer transformer operations 
preserve this invariant, including unitWT, bindWT, and the formal- 
ized versions of tell and listen. 

The reader may verify that the function Am. bindWT m unitWT 
is indeed a deflation. But we are not quite done showing that the 
subtype defined by INV is a monad: Because the left unit law does 
not hold universally for the writer transformer, we must also verify 
that all values in INV satisfy the left unit law as well. 

k x € INV => bindWT (unitWT x)k = kx (49) 

Unfolding the definition of INV, we see that it is sufficient to show 
bindWT (unitWT x) k = bindWT (k x) unitWT. This can easily be 
proven by applying runWT to both sides and simplifying. 

In summary, we have seen that the writer monad transformer is 
not quite a true monad, because the type contains values that do 
not respect the monad laws. But when we view it as an abstract 
datatype, with an interface that exports only operations that pre- 
serve the datatype invariant, it is valid to treat it as a real monad. 



7. Conclusions and related work 

The Tycon library for Isabelle/HOLCF is now available at the 
Archive of Formal Proofs |6|. It allows users to define, reason 
about, and instantiate constructor classes with little effort. It mod- 
els polymorphism using coercion from a universal domain, which 
allows it to work in ordinary higher-order logic. 

A different domain-theoretic model of polymorphism is pre- 
sented by Amadio and Curien 1 1 1. Here, polymorphic functions are 
modeled as functions from types (i.e. deflations) to values. How- 
ever, this model allows non-parametric polymorphic functions that 
depend non-trivially on the type argument. Also, building a Tycon 
library around this model would also require users to write explicit 
type abstractions and applications when instantiating constructor 
classes; it is not clear whether this would be practical for users. 

Sozeau and Oury |15] have recently developed a type class 
mechanism for the Coq theorem prover. Coq has a powerful de- 
pendent type system that allows reasoning about type constructors, 
first-class polymorphic values and type quantification. They define 
a monad class, including monad laws. Their system has the capa- 
bility to formalize the whole monad class hierarchy, and it appears 
that it could be used to verify monad transformers; however, we are 
unaware of any published work in that direction. 

Formalizing monad transformers in Coq does have some limi- 
tations compared to the Tycon library. For example, Coq does not 
accept the type definition of the resumption monad transformer: To 
ensure the strict positivity requirement, indirect recursion can only 
be used with known type constructors, not a monad parameter. An- 
other difference (not necessarily a limitation) is that Coq is a logic 
of terminating functions, and does not include notions of bottoms, 
strictness, or partial values. Results proved in such a logic must be 
interpreted differently. 

Our earlier formalization of axiomatic constructor classes |7| 
could express many of the same definitions as the current work. 
However, it did not provide as many features or as much automa- 
tion for users. Instead of naturality laws, it used a deflation mem- 
bership relation, written x ::: d, to express the fact that polymorphic 
functions had the right type. For example, the Monad class there 
had a rule for return that stated Vx ::: d. return x ::: \r\(d). Trans- 
fer proofs to establish polymorphic laws were lengthy and unprinci- 
pled, making subclass definitions impractical for users. Automation 
for instantiating the Functor and Monad classes was present, but it 
required users to define finap on a separate copy of the datatype 
first. Users were then left without a good way to transfer properties 
to the new Tycon version of the type. 

Automation for theorem transfer in the Tycon library is much 
smoother than it was in our earlier work, but there is still room 
for further improvement. Currently we rely on a set of rewrite 
rules, which works well in practice so far. However, the behavior 
of such rewriting strategies is often hard to predict, the rules were 
assembled in an ad hoc fashion, and we have no convincing reason 
to trust that the method will work in all situations. 

A better approach would be to use a more principled theorem 
transfer method, like the quotient packages developed recently by 
Homeier |3| and Kaliszyk & Urban [ 10 1 . For functions respecting 
an equivalence relation, theorems can be transferred from the un- 
derlying "raw" type to a quotient type. In HOLCF, type U could be 
considered as a raw type, with a representable type a as a quotient 
type; the pro] function induces an equivalence relation on U. The 
naturality laws for operations on U could then serve as the respect- 
fulness theorems required by the quotient package. 
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